コンテナのアツい鼓動と変な熱気に包まれたJAWS-UG コンテナ支部に参加してきた #jawsug_ct

コンテナ界隈の熱気を感じるJAWS-UG、コンテナ支部のイベントに参加してきました。

#イベントレポート

#Kubernetes

#Docker

#AWS Fargate

#Amazon EKS

濱田孝治

2018.06.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「コンテナ界隈、あっつあっつやで…」

クラスメソッドAWS事業部におりますと、そりゃいろんなJAWSのイベントにお伺いすることが良くあるんですが、自分コンテナ支部ははじめての参加でした。

JAWS-UG コンテナ支部 #12 - connpass

いやぁコンテナ界隈はアツい。参加者も大人数で楽しい時間を過ごさせてもらいましたので、その熱気をご報告致します（冒頭画像は、上記イベントページのトップ絵を借用させていただいております）。

　__
（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     ｺﾝﾃﾅ ﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

ごっつ素敵なエウレカ様オフィス

今回のJAWS-UG　コンテナ支部の会場はeureka, Inc.のオフィスでの開催となりました。

自分にとっては初耳の会社様だったのですが、Pairs(ペアーズ) - Facebookを利用した恋愛・婚活マッチングサービスと聞けば、ピンと来る人も多いんじゃないでしょうか。自分のtwitterのタイムラインにも、ごっつでてきます（真顔）。

会場の様子。今どきの広々として明るいスペース。素晴らしいすね。スクリーンも2台設置。

壁面も綺麗でお洒落。

この反対側にはガラス張りで区切られたエウレカ様のオフィスがババーンとでてました。ババーンとね。

JAWS-UG　コンテナ支部 #12の講演内容

JAWS-UG コンテナ支部 #12 - connpass

タイトル	講演者
Amazon Elastic Service for Kubernetes （EKS）の紹介	Amazon Web Services Japan　福井厚さん
FiNCを支えるインフラ技術　〜ECSとDevOps〜	株式会社 FiNC 中村　郷史さん
AWS初学者がDevOpsツールを作ってみた	株式会社ビズリーチ様
EKSにシュッと入門〜GKEからの移行〜	株式会社エウレカ SRE チーム　坂田　純さん

その他にもLTがあったのですが、今回は割愛させていただいてます。

Amazon Elastic Service for Kubernetes （EKS）の紹介

トップバッターはアマゾンウェブサービスジャパン株式会社の福井厚さん。

この間のAWS Summit Tokyo開催直後に発表されたEKS（Amazon Elastic Container Service for Kubernetes）について、話を伺います。

EKSとは？

オープンソースとしてのKubernetesの特性はそのまま活かしつつ、AWSのマネージド・サービスとの連携を強化している。

EKSはエンタープライズ企業が本番のワークロードを実行するためのプラットフォームであること
EKSはネイティブで最新のKubernetesの体験を提供すること
EKSユーザが他のAWSサービスを使う時、シームレスな連携を実現し不要な作業を取り除くこと
EKSチームは積極的にKubernetesプロジェクトに貢献していくこと

Amazon EKSはKubernetes Certifiedを取得している。お墨付きですよ。

EKSを学ぶには？

何はなくとも、Getting Started with Amazon EKSが用意されているので、それを実施してみて、手で動かして学んでみましょう。

手順の内容は以下の通り。

Amazon EKS サービスロールの作成
Amazon EKSクラスタ用VPCの作成
kubectlのインストールと構成
heptio-authenticatorのインストール
EKSクラスタの作成
Amazon EKSのためのkubectl configuraltion
Workerノードの起動と構成
アプリケーションの起動

VPCの作成なども、専用のCloudFormationが用意されているので、合わせて実施してみて欲しい。そんなに苦労なくできるはず。

EKSのネットワーク周辺機能

IAM Authentication + KubeCtl

EKSの特徴は、AWSリソースとの連携。権限周辺の制御で重要なIAMに関しては、以下のフローで制御される。

AWS IDはRBAC（Role Base Access Controll）で認可され、K8sの各アクションの認可をする。そこで利用されるモジュールがheptio。

ネットワーキング基盤として、CNIの活用

EKSはCNIに準拠。CNIプラグインによるネイティブVPCネットワーキングに対応し、複数のPodはVPC内に存在するようにPod内に同じVPCアドレスを持つ。

GitHub上で公開されているので、気になる方は是非参考にしてもらいたい。

containernetworking/cni: Container Network Interface - networking for Linux containers

AWSの記事も公開されているので、合わせて参照されたい。

Exploring the Networking Foundation for EKS: amazon-vpc-cni-k8s + Calico | AWS Open Source Blog

TigeraのCalico対応

Tigera Calico Policy Generally Available on Amazon EKS

Kubernetesのネットワークポリシーによってネットワーク・セキュリティルールを強制。CallicoはネットワークポリシーAPIの実装をリードしており、CNIプラグインと連携し、きめ細かなネットワークポリシーを提供。これにより、Kubernetes APIを使用してマイクロサービス単位でアクセス制御を実現可能。

ロードバランサー

AWS ALB IngressコントローラーをAWSがサポート。ALBの機能をIngressリソースを通じてKubernetesへ公開。L7ロードバランシング、ホスト名またはパスによるコンテントベースのルーティングをサポート。

サービスディスカバリ

ExternalDNSへコントリビュート、K8s Incubator project。

KubernetesサービスとIngressをAmazon R53オートネーミングサービスレジストリに登録
Amazon R53へのシンプルなDNSクエリを通じてKubernetesとAmazon ECSクラスタを横断してサービスディスカバリーを有効化
VPC内またはパブリックでのサービス実行をサポート

ログの集約

Fluentdを通じてCloudwatch Logsにログを集約可能。

濱田感想

EKS全くのド素人で、GettingStartedをこの間やってみたばかり（参考：【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた）だったのですが、知らない要素が多くて、すっごいためになりました。

まだCNIやCalicoあたりを触れてないので、Kubernetesをあれこれいじってみながら、どんどん知見をためていくための良いきっかけになりますね。

講演の中では、今東京リリース前であっついFargateや、Codeシリーズの紹介もあり、DevOpsスペシャリストという役職の厚みを感じさせるてんこもりの講演で楽しかったです。今後も、Blackbeltなど、要チェックでございます。

FiNCを支えるインフラ技術　〜ECSとDevOps〜

講演者は、FiNC社の中村　郷史さん。

なぜECSにしたのか？

スケール性能
- コンテナ（サーバ）増速の速さ
リソース最適化
- 1台のサーバリソースを使い切れる
多様な構成管理、異なる設定管理
- SREが中央管理するのではなく、開発側に移譲

発表内容の全体像はこちら。

デプロイフロー

DBのマイグレーションのデプロイフローはこちら。

DBのマイグレーションは、utilityクラスタのコンテナの中でサービスを更新し、画像アップロードとDBマイグレーションを実行。その後、Applicationクラスターを更新する流れとなっている。

テストフローはこちら。

GitHubへのコミットを起点にイメージからコンテナを起動。必要パッケージをインストールし、db create後にテストコードを実行。

ここで環境構成をチェックする方法を導入。対象ファイル、ディレクトリ全体をSHA256に変換。インストールにDockerfile、Gemfile、マイグレーションにdb/migrateを利用。

改善版のテストフローはこちら。

config checkを導入することでディレクトリやファイルの整合性の検証を実施している。

オートスケール方法

ECSのスケールイン/アウトの方式がこちら。

unicorn worker numでメトリクスデータをNew Relicに送信。そこからLambdaでメトリクスを取得しその情報をCloudWatchに送信し、スケールイン/アウトのトリガーが発動される。

EC2のスケールアウト方式がこちら。

こちらでは、EC2のCPU利用率をCloudWatchで監視し、LambdaからCloudWatchを確認し、EC2のdraining/terminateを実行している。

バッチ処理

バッチ処理には、Jenkinsを利用。ジョブの制御には社内自家製ツールを利用しており、そこからタスク定義の検索、リポジトリ検索、docker pullからのコマンド実行を実施している。

fluentdの構築

awslogsではなくfluentdを使っている主な理由は、コスト面。プロダクション環境で吐き出されるログの量から計算すると、月10000$を超える計算となり、fluentdを使うこととなった。

fluentdに障害が発生したときに、コンテナが起動しない問題があった。原因は、fluentdのAggregatorで全アプリケーションの全種類のログを受けておりSPOFになっていたため、一度Aggregatorに障害が発生したときに、コンテナ起動時にその通信ができないことでコンテナが起動しないという事象が発生した。

改善例がこちら。

各コンテナインスタンス内に1つずつfluentdのクライアントコンテナを導入。そこから、各ログ種別にわけたfluentdAggregatorに分けて送信することで、SPOFを回避した。

ワーカーの監視方法

非同期処理を実行しているワーカーが処理中にコンテナが停止してしまい、最初から処理を再開する事態が発生。ECSタスクの停止動作には、以下のコマンドを利用していた。

$kill -SIGTERN (kill -15)
$kill -SIGKILL (kill -9)

改善点として、以下の停止シグナルを送ってから、停止するまで待つようにした。

$kill -USR1

このため、コンテナ監視環境を社内で構築した。ワーカーの監視方法がこちら。

稼働中のタスクの最大メモリとワーカー数を確認、SystemsManagerにメモリとワーカー数を問い合わせ、最大メモリ値を超えたタスクに対して、上述したユーザ停止シグナルを送りタスクを終了させる構成とした。

濱田感想

ECS運用に関する活きたTIPSが満載で聞いていて非常に楽しかったです。アプリケーションはRailsで構築されていたかと思うのですが、普段のDevOpsの文脈ではあまり話題にあがらない（？）DBマイグレーションの話があったり、最後のワーカーの監視方法などは独自性が強く、興味深い点でした。

実運用しているならではのTIPS、貴重ですね。似たようなシチュエーションで困ったときには参考にさせてもらいたいなと思いました。

AWS初学者がDevOpsツールを作ってみた

講演者は、株式会社ビズリーチの渡部未来（ABAB↑↓BA(@ababupdownba)さん。

ビズリーチについて

いわゆるひとつのこれの会社です。最近みなさん、よく見ていただいているかと思います。

SRE/インフラエンジニア絶賛募集中です。

SRE/インフラエンジニア（HRMOS） | 株式会社ビズリーチ

どしどし応募くださいませ。

アジェンダは以下の通り。

Elmの紹介
HRMOS採用管理のサービスアーキテクチャ
HRMOS採用管理の開発における問題と対策
自分に何ができるか
Panopticon
まなび

Elmの紹介

面白いからやってみて（断言）

ElmはWebアプリケーション（フロントエンド）を開発するための言語。AltJSで、言語がフレームワークを内在。関数型で型安全機能もあり、高い生産性を誇る。

HRMOSのアーキテクチャ

アーキテクチャはこちら。ECSアプリケーションとしては非常に一般的な構成かと思います。

ステージング/本番環境の構成はこちら。

開発環境では、インスタンスにSpotFleetを使用して、コストを抑えています。

ECS利用の規模感は以下の通り。

サービス（モジュール数）：35
タスク数：54
コンテナインスタンス：29

HRMOS採用管理の開発における問題と対策

検証のため、PullRequest毎に環境のサブセットを作って機能テストを実施。

これには、問題があった。各チケット単位（プルリクエスト）で環境のサブセットが用意されているため、あるはずのモジュールがなかったり、テストがうまくいかない時に環境の存在確認に時間がかかったり、無駄に手間が増えていた。

SREチームでも、Sandbox環境を提供してくれたり、積極的な権限付与をしてもらったり、AWSコンソールツアーを実施してもらったりした。

そこでElmを書きたくなった。

AWSにはいろんなコンポーネントがあって誘惑が多い。そこで。自分の得意分野（Elm）で勝負しようと思ったのがきっかけである。その後、ECSをひたすら勉強して出来上がったのがPanopticonである。

Panopticonとは？

Lambdaでboto3経由で、ECSの情報を取得
- API GatewayやデプロイやServerless Frameworkを利用
S3でElmの生成物（index.html + bundle.js）を配信

そうして出来上がったのがこちらの画面です！是非雰囲気を感じてください！

今後、以下の展開を検討中。

Panopticonを用いた、開発者向けECS講習の実施
(需要があれば)OSS化
サービス化？
KubernetesやGCPにも対応？

今回の開発における学び

AWS超楽しい
得意分野と合わせることで苦手分野は克服できる！
新たなキャリアは自分で切り開くもの！
他のメンバーを苦手分野に巻き込む理由雨ができる！
新しいことをスパルタ式でやると圧倒的成長が！

濱田感想

めっちゃ聞いていて面白かったです。はい。Elmとかは正直全然しらなかったんですが、AWS経験がほぼない初学者の状態から2週間ほどでここまで作り上げる圧倒的スピード感には、会場全体が驚いてましたね。

出来上がったPanopticonの動画も是非見てみてください。皆さん、普段ECSのコンソールを使っていて辛さを感じたことないでしょうか？自分はありますｗ。ある程度触りまくってみないと、クラスタ、サービス、タスク、コンテナインスタンスの階層構造を掴むのに苦労するんですよね。特にクラスターとサービスの関係は慣れが必要だった記憶があります。

もちろん、AWSコンソールには必要なオペレーションをすべて含めて置く必要があるのでUIが一筋縄ではいかないのは理解しているつもりですが、Panopticonは、クラスターとサービスとタスクの包含関係が非常に直感的に表現されていて、わかりやすいんですよね。

一番最初、ECSを触り始めたときの「構成をイメージすることの難しさ」に対して、非常に便利なソリューションかと感じました。

OSS化も視野に入れている（？）とのことなので、正座で待機しようと思います！

（おまけ）講演中のツイート群

当日の会場の雰囲気は、以下のツイート群から察してください。

優秀な若者 #jawsug_ct pic.twitter.com/XVXOgeDfKF

— ポジティブな Tori (@toricls) 2018年6月21日

これ、2週間でできてるってのが半端ない・・・#jawsug_ct

— TAKAHASHI Kunihiko (@kunit) 2018年6月21日

ビズリーチさんの若者のプレゼン面白すぎる。Elmへの情熱が熱すぎる。でも冷静に見ても落ち着いた喋り、笑いを取れるプレゼン。AWSのコンソールすら知らなかったいまどき？（というか今後世の中はそっちに寄っていく？）エンジニア。 #jawsug_ct

— YoS (@17_YoSK) 2018年6月21日

Elm!Elm! 帰ったら書いてみたい気持ちでいっぱい。 #jawsug_ct

— ま? (@memo_mamimu) 2018年6月21日

いや、みんな Elm で笑ってるけど手持ちの武器をうまく使ったという意味ではとても良い事例だと思いますよ。ただ、こういう Ops ツールを内製すると後々負債になりがちなのでおじさんはそれが心配。特殊な技術だとなおさらそう。#jawsug_ct

— チェシャ猫 (@y_taka_23) 2018年6月21日

Elmとか初耳でした。